无服务模型导致云原生产生哪些风险

无服务模型导致云原生产生以下这些风险：

• 服务商风险：云服务商对无服务器的防护还很薄弱，虽然无服务器已经很普遍，但是无服务器功能，会让整个基础设施变得更抽象，让问题更严重。网络攻击者会寻找容器和无服务器代码中的隐患，以及云基础设施中的错误配置，以接入包含敏感信息的实体，再用它们提升权限，攻击其他实体。

• Key的泄露：云原生应用对资源和设施的管理和使用基本都是基于Key，因此针对云原生的攻击首先的变化就是对key的攻击。根据统计，用户的apikey无意泄露在github等网站其实是很常见的，因此有黑客专门去这些网站扫描无意提交的key信息。云服务商为了应对这种新攻击，基本都与GitHub这些主流的网站进行合作，主动扫描发现这些泄露的key并及时通知其客户消除风险。

• 云原生配置风险：无服务器使用的资产是品类多、动态的、用完即走的，各种安全配置分散在各个产品中，缺乏统一管理和运维平台，难以做到管理和检查，从而导致配置安全和隐患，配置安全这个是容易被忽略的。多产品联动已经足够困难，更棘手的是，不少项目会跨厂商联动，比如组合了阿里云、腾讯云、高德开放平台、百度云等的产品，造成难度系数陡增。

• 资产多：采用云原生的时候，资产比较隐蔽变化也快，这个需要云服务商多多工作，同时跨厂商的使用让复杂度也更提升

• API风险：无服务器是细粒度的服务，他的安全重点也就是API安全，如API异常调用、越权操作、违规调用。

• 内部审计风险：云服务商的无服务器无法保障细粒度的操作的记录和安全性，如更新代码人员、部署新服务人员、删除函数人员等，或要想实现付出的成本很高昂。

• 功能天然风险：当前包括腾讯云的云函数在内的主流无服务器云服务商，都提供了镜像部署和代码部署两种方式。在安全方面，镜像部署面临更多的安全风险（如镜像安全风险、镜像仓库安全风险）。

• 安全变量风险：若将配置或敏感信息保存在环境变量，一旦被突破这些信息直接泄露、被修改甚至被利用。建议：少用或不用环境变量，因此复杂的环境配置而导致必须用镜像部署的，应该考虑将各种环境变量配置使用配置文件

• 攻击面广：无服务器中微服务模式部署有着其先天的优势而一定成为主流，但微服务随之带来了新的风险，可供攻击的面也更广泛；建议：采用“零信任”的理念来处理每次的访问的安全防御。

• 环境变量风险：使用环境变量替代配置文件虽然存储更简单，但是使用环境变量本就是不安全行为，攻击者进入运行环境，可以轻易获取、修改环境变量信息，引发信息泄露。腾讯云的文档做的就不好，竟然有把数据库的账号密码配置在环境变量

• 资源权限管控风险：传统的基础设施是静态的，无服务器中基础设施的出现和使用是函数级动态的，因此每个函数与资源的权限映射会非常多，如何高效进行角色和权限的管控是个复杂问题，很多开发者暴力为所有函数配置单一角色和权限，这一行为极大增加函数使用风险。

• 跨函数调用数据清理不及时引入数据泄露风险：在运行过程中，调用结束后没有及时清除暂存的配置参数、账号信息或其他业务敏感信息，后续调用的函数访问时，可能存在越权和获取机密数据的情况。在“单实例多并发”或“请求多并发”功能的加持下，这个风险又会额外增加。建议：函数执行时，不要偷懒直接复用当前已经存在的文件、内存变量、配置信息等，而是每次都应该视为全新使用，有临时存储的需求时，必须检测操作的成功与否，以免误用历史信息。

• 缺乏无服务器专有安全解决方案：现在的安全工具和安全体系是基于云场景中的虚拟机或容器底座，基于web应用或传统框架进行设计开发和应用的。在servless上这些无法直接匹配或使用。

• 钱包攻击：传统攻击以阻塞业务为目标，无服务器的安全性让攻击者无法阻塞其业务，只能转而进行钱包攻击。